📦 Binary Size-limit

Comparing 4aea304 to chore(deps): update dependency terser-webpack-plugin to ^5.6.1 (#14393) by renovate[bot]

❌ Size increased by 248.25KB from 62.67MB to 62.91MB (⬆️0.39%)

Rsdoctor Bundle Diff Analysis

Found 5 projects in monorepo, 5 projects with changes.

Generated by Rsdoctor GitHub Action

Merging this PR will degrade performance by 2.07%

❌ 1 regressed benchmark
✅ 51 untouched benchmarks
⏩ 36 skipped benchmarks¹

Performance Changes

_{Comparing codex/runtime-proxy-context-redesign (4aea304) with main (42487d9)}

Deploying rspack with    Cloudflare Pages

View logs

@codspeedbot explain the regression

@codspeedbot explain the regression

Regression analysis

I compared the latest head run (4f558e9) against main (c3c2717) and profiled both flagged benchmarks. Here's what's going on.

What regressed

Why it's very likely incidental, not a real hot-path regression

Both benchmarks measure compilation stages that never execute any of the code this PR touches. This PR changes runtime-context rendering (__rspack_context, experiments.runtimeMode, runtime module/global handling), but:

• create_named_chunk_ids — time is dominated by find_graph_roots / ChunkGraph::get_chunk_root_modules (~70%), sort_unstable_by_key, and ESMImportSpecifierDependencyCondition::is_connection_active. None of these are modified by the diff.
• mangle_exports — time is dominated by mangle_exports_info, optimize_code_generation, and allocator activity (mimalloc mi_* / _mi_page_malloc). Again untouched by the diff.

In both flamegraphs the regressed frames are overwhelmingly memory/cache-bound rather than doing more instructions (e.g. in create_named_chunk_ids, Option::as_ref is ~86% memory cost and the chunk-name closure is ~76% memory). That signature — unchanged call trees, costs shifting in the memory dimension — is the classic fingerprint of binary layout, inlining, and allocation-pattern shifts, not an algorithmic change. It lines up with the reported binary-size growth (+228 KB / +0.36%) from adding the new runtimeMode code path and config field: new code reshuffles symbol placement and allocation order, which nudges cache behavior in hot loops elsewhere.

Recommendation

• The ~2.3–2.75% movements are small, in stages your PR doesn't functionally alter, and consistent with incidental layout/allocation noise rather than a true regression.
• If you're satisfied with the analysis, you can acknowledge them on CodSpeed to clear the warning.
• Note: the report header also flagged an Unknown Walltime execution environment — these two benchmarks run in Simulation mode (deterministic), so they aren't affected by that warning, but any Walltime benchmarks on standard hosted runners will be noisier. Macro Runners give the most stable Walltime numbers.

No code changes are needed for this — it's an explanation, not a fix. If you'd like, I can dig deeper into a specific frame or help confirm by isolating the config-field change.

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

📝 Benchmark detail: Open

Base persistent cache hit rate: 👍

Current persistent cache hit rate: 👍

📝 Rspack Ecosystem CI: Open

📝 Rspack Ecosystem CI: Open

suite result
rspress ✅ success
rslib ❌ failure
modernjs ✅ success
rstest ❌ failure
devserver ✅ success
rsbuild-rsc-plugin ✅ success
examples ✅ success
plugin ❌ failure
rsdoctor ✅ success
lynx-stack ✅ success
rsbuild ✅ success

same with the latest main commit and just some new lines in snapshot

@codspeed explain the regression

@codspeed explain the regression

Regression analysis

I re-checked the latest head run (14c80a9) against main, and the regression no longer reproduces.

✅ 52 unchanged · ⏩ 36 skipped · 0 regressed

What happened

The earlier flags — the WallTime bundle@threejs-10x-production-sourcemap (-2.07%) and the Simulation create_named_chunk_ids / mangle_exports (~2.3–2.75%) movements — were incidental, not a real hot-path regression:

• Those benchmarks exercise compilation stages (chunk-graph root finding, export mangling, codegen/allocation) that this PR does not functionally touch. The PR only changes runtime-context rendering (__rspack_context, experiments.runtimeMode, runtime module/global handling).
• In the flamegraphs the affected frames were overwhelmingly memory/cache-bound rather than executing more instructions — the classic fingerprint of binary-layout, inlining, and allocation-pattern shifts caused by adding the new runtimeMode code path and config field (consistent with the small +228 KB binary-size growth), not an algorithmic change.

On the current head these effects have washed out and all 52 measured benchmarks are within noise.

Recommendation

No code changes are needed — this was incidental noise, and the latest run is clean. The remaining warning on the report header is the Unknown Walltime execution environment notice: WallTime benchmarks on standard hosted runners are inherently noisier. For stable WallTime numbers, CodSpeed Macro Runners are recommended; the Simulation benchmarks are deterministic and unaffected by that warning.

If you'd like, I can re-run the comparison against any specific base commit or dig into a particular benchmark's flamegraph.

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}